Account Management Biz Api
PATCH-BIllingAccountByID for v4r1
[TOC]
V4r1/billingAccount/{id} [PATCH]
This operation allows partial updates of a account entity.
Method Logic
graph LR
id1((client)) --> request
request --> process
process --> response
response --> id1
Process sequence diagram
sequenceDiagram
participant Client
participant biz as account-management-biz
participant sfdc as sfdc-sys
Client ->> +biz: PATCH [REST]<br> v2/billingAccount/{id}
alt else
biz->> +sfdc: PATCH [REST] <br>v2/billingAccount/{id}
note over sfdc: Tranformation<br>Request1
sfdc-->>-biz: 200
note over biz: Tranformation<br>Response1
end
biz-->>-Client:200
alt invalid input or unsupported message type then
activate biz
biz-->>Client: 400
deactivate biz
else authentication invalid then
activate biz
biz-->>Client: 401
deactivate biz
else request not found then
activate biz
biz-->>Client: 404
deactivate biz
else businessId not implemented then
activate biz
biz-->>Client: 501
deactivate biz
else server not available or timeout then
activate biz
Client-->>+biz:
note over biz: takes too long
biz--x-Client: 500
deactivate biz
end
Uses Cases
The internal use cases to the method are defined.
Case | Description |
---|---|
1 | Enable/Disable Autopay |
Request
This section defines all the possible data structures sent by the client when consuming the method.
URL
https://[localhost]:[port]/tmf-api/accountManagement/v4r1/{businessId}/billingAccount/{id}
URL PARAMS
name | type | description | required |
---|---|---|---|
businessId | string | 2 letter ISO 3166 country code (TT, BB, JM, PA, etc.) identifying the business unit. | Y |
id | string | Unique identifier of the account | Y |
Header
name | value | description | required |
---|---|---|---|
client_id | string | The client_id identifying the channel. | Y |
client_secret | string | Password associated with the client_id. | Y |
X-Correlation-ID | string | Identifier that correlates HTTP request between a client and server. Any identification model (UUDI, checksum, etc.) can be used, as long as it is a unique value to differentiate a transaction. Note - Mule default behavior creates a sample x-correlation-id field if value is not passed from client, API will use this value in case value is not passed in API request | Y |
Body
Request
In this section all the possible data structures received by the client at the moment of responding the method are defined.
{
"defaultPaymentMethod": {
"@referredType": "AutoPay",
"id": "PAYMENT-9901"
},
"extendedCharacteristic": [
{
"value": "True",
"name": "restrictOrder"
}
],
"relatedParty": [
{
"id": "345687234",
"@type": "msisdn"
},
{
"name": "Digital",
"@type": "channel"
}
]
}
Definitions of the request body
name | type | description | required |
---|---|---|---|
defaultPaymentMethod | Object | Payment method object | Y |
defaultPaymentMethod.@referredType | String | Default payment method type | Y |
defaultPaymentMethod.id | String | Default payment method payment-id | Y |
extendedCharacteristic | Array | Characteristic Array | N |
extendedCharacteristic.value | String | Relevant characteristic value | N |
extendedCharacteristic.name | String | Relevant characteristic name | N |
relatedParty | Array | Related party Array | Y |
relatedParty.id | String | value of the reference | N |
relatedParty.@type | String | reference related party type. | N |
relatedParty.name | String | name of the reference ex: Digital | Y |
relatedParty.@type | String | reference related party type. ex: channel | Y |
Response
In this section all the possible data structures received by the client at the moment of responding the method are defined.
Possible response success
This section defines all the possible data structures received by the client and that must be considered satisfactory at the time of responding to the method.
[ 200 ]
OK - PATCH request processed successfully, response body contains an entity corresponding to the requested resource.
{
"status": 200,
"description": "Autopay change request received"
}
Possible response error
In this section all the possible data structures received by the client are defined and that must be considered as unsatisfactory when responding to the method.
name | type | description | required |
---|---|---|---|
status | Number | status code | Y |
description | String | status description | Y |
[ 400 ]
Bad Request - the request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications.
{
"errors" : [{
"code" : 400,
"message" : "The request is invalid or not properly formed.",
"description" : "The requested operation failed because is not properly formed or is invalid."
}]
}
[ 401 ]
Unauthorized - The request has not been applied because it lacks valid authentication credentials for the target resource.
{
"errors" : [{
"code" : 401,
"message" : "The user could not be authenticated for this request.",
"description" : "The request has not been applied because it lacks valid authentication credentials for the target resource"
}]
}
[ 405 ]
Method Not Allowed - HTTP method not allowed for this resource. The method specified in the Request-Line is not allowed for the resource identified by the Request-URI.
{
"errors": [{
"code": 405,
"message": "APIKIT:METHOD_NOT_ALLOWED",
"description": "HTTP Method POST not allowed for : /{businessId}/billingAccount/{id}"
}]
}
[ 429 ]
Too Many Requests - client has sent too many requests in a space of time (rate limiting). When a server is under attack or just receiving a very large number of requests from a single party, responding to each with a 429 status code will consume resources. Therefore, servers may drop connections or take other steps instead of responding with the 429 status code, when limiting resource usage.
{
"errors" : [{
"code" : 429,
"message" : "APIKIT:TOO_MANY_REQUESTS",
"description" : "The client sent too many requests and server is not able to serve them all at the moment"
}]
}
[ 500 ]
Internal Server Error - server encountered an error processing request. This should not happen normally, but it is a generic error message, given when no more specific message is suitable.
{
"errors" : [{
"code" : 500,
"message" : "The request failed due to an internal error.",
"description": ""
}]
}
[ 501 ]
Not implemented - indicates that the server does not support the functionality required to fulfill the request. This is the appropriate response when the server does not recognize the request method and is not capable of supporting it for any resource.
{
"errors" : [{
"code" : 501,
"message" : "Not implemented",
"description" : "Operation PATCH /billingAccount/id for Business Id: 12345 not implemented"
}]
}
Administration and data management
In this section you define all the transformations, temporary and final repositories of the data within the method flow.
Transformation Request
In this section the matrix of all the data transformations that is carried out within the service is defined.
Note: Same input payload will pass to the next layer without transformation
Original Payload | Mulesoft | transformation |
---|---|---|
payload | payload |
Transformation Response
In this section the matrix of all the data transformations that is carried out within the service is defined.
Note: Same output payload will pass from SYS layer without transformation
Original Payload | Mulesoft | transformation |
---|---|---|
payload | payload |
Services dependencies
This section defines all the connections to the web services and the methods that are used within the method.
sfdc-sys
Method | Type |
---|---|
/billingAccount/{id} | PATCH |